SEGURIDAD LÓGICA y TESTING DE PENETRACIÓN
PENETRATION TEST:
Es una técnica o procedimiento diseñado para probar todas las posibles vulnerabilidades existentes en un sistema, que permitan evitar los controles de seguridad y ganar acceso a recursos o información crítica. Su objetivo es medir la capacidad de las medidas defensivas de una organización frente a posibles ataques, descubriendo las debilidades de su entorno. Un “Penetration Test” emula los mismos métodos que emplearía un posible atacante.
PenetrationTest (Cont.)
En su accionar, puede evaluar:
- Puertos abiertos
- Servicios disponibles
- Web Servers
- DNS Servers
- Mail Servers
- Configuraciones de Routers
- Configuraciones de Firewalls
- Vulnerabilidades de OS y estaciones de trabajo
- Acceso a información clasificada
- Accesos remotos, etc.
PenetrationTest (Cont.)
El tipo de “Penetration Test” depende de la organización, en particular de sus objetivos de seguridad. Puede ser ejecutado en forma '' externa `` o''Interna ``, e incluye inicialmente un análisis de vulnerabilidades, pero a diferencia de éste, aquí se intenta explotar las vulnerabilidades encontradas. El resultado obtenido, es un reporte proporcionado a la gerencia, que describe las vulnerabilidades identificadas y el grado de riesgo asociado, con recomendaciones de cómo solucionar el problema en forma adecuada.
Browsing: se da cuando intrusos obtienen información que no deberían conocer.
Sniffers: es una herramienta que monitorea el tráfico que circula por la red, con el fin de diagnosticar problemas.
Session Hijacking: se produce cuando un atacante quiere tomar control de la sesión entre dos computadoras sin ser detectado.
Password Cracking: Este tipo de passwords puede ser fácilmente vulnerado. Una vez que los datos de un proceso de autenticación son capturados, el atacante puede iniciar un “crack” de la password a través de técnicas como “Diccionario” o “Fuerza Bruta”.
Backdoors: son insertados dentro del código de un sistema, de manera de permitirle al desarrollador ganar acceso al mismo, evitando los procesos de autenticación y autorización, en caso de existir problemas en los métodos de acceso normales.
DoS/ DDoS: los ataques DoS pueden ser realizados por medio del envío de paquetes malformados a la pila de red de un sistema determinado. Esto podría resultar en que el sistema objetivo, al no poder procesar correctamente este tipo de tráfico, se desborde o deje de realizar su tarea.
SYN Flood: se basa al momento de establecer una sesión, en lo que se conoce como el saludo de tres vías o conexión de tres pasos (SYN –SYN/ACK –ACK). Si el paso final no llega a establecerse, la conexión permanece en un estado denominado "semiabierto" El ataque SYN Flood Se produce cuando el atacante envía a la víctima, gran cantidad de paquetes spoofeados con origen falso sin previamente cerrar la conexión anterior (ACK). Si el sistema víctima posee un límite bajo en el número de conexiones "semiabiertas" que puede manejar en un momento determinado, y este límite es superado, el servidor sencillamente dejará de responder a las nuevas peticiones de conexión que le vayan llegando causando la denegación de servicios.
PRUEBAS CUMPLIMIENTO
Las pruebas de cumplimiento consisten en recolectar evidencia con el propósito de probar el cumplimiento de una organización con procedimientos de control. Esto difiere de la prueba sustantiva, en la que la evidencia se recoge para evaluar la integridad de transacciones individuales, datos u otra información.
Una prueba de cumplimiento determina si los controles están siendo aplicados de manera que cumplen con las políticas y los procedimientos de gestión.
Existe un conjunto de técnicas que se basan en verificar por medio de una muestra de transacciones (reales o ficticias) las funciones de procesamiento con la finalidad de permitir al auditor comparar los resultados de “su” procesamiento con los reportes brindados por el sistema real.
Tipos de pruebas de cumplimiento:
- Ejecución manual del procesamiento
Se re-ejecuta el proceso que se quiere controlar en forma manual, a partir de los datos reales (para lo cual se toman muestras de los mismos). Los resultados obtenidos se comparan manualmente con los que oportunamente generó el computador. Solamente se podrá aplicar esta técnica, en tanto y en cuanto exista documentación o fuente de obtención que provea los datos requeridos para la re-ejecución con cierta facilidad.
Consiste en formar un conjunto de datos de entrada, reales o ficticios, para hacerlos ingresar en grupo al computador a fin de ser procesados con el mismo programa que se encuentra en operación. Trabaja con una copia de los programas y de los archivos en uso (en producción) y tiene por objetivo comprobar el funcionamiento de los programas. Esta técnica no está diseñada para controlar el contenido de los archivos, por ello raras veces permite detectar operaciones fraudulentas.
En el lote a procesar en el computador se deben incluir todos los posibles casos (con características distintivas) de los registros a procesar. Los resultados se compararon con los que haya arrojado el procesamiento en forma manual de los mismos datos. Es sumamente importante considerar que el lote de prueba incluya todas las posibles situaciones que pudieran ocurrir durante las operaciones reales.
Se utilizan los archivos reales de la entidad y se simula el procesamiento de la aplicación mediante programas especialmente preparados. El auditor elabora sus propios programas; éstos deben procesar los mismos datos que los programas de la aplicación a auditar. Luego ambos resultados son comparados.
Para lograr su cometido, la simulación necesita disponer de los datos reales de entrada y los archivos usados en su procesamiento. Con estos elementos se efectúa la ejecución del proceso (on line) o la “corrida” (batch) de simulación, comparando a continuación los resultados con los que produjo el procesamiento real. Más tarde se evaluarán las excepciones obtenidas de la corrida de simulación, entendiéndose por tales, las anomalías detectadas en el proceso de reconciliación. Estas excepciones se tendrán en cuenta a la hora de hacer las recomendaciones.
Requisitos para realizar una simulación paralela
- Relevamiento de la aplicación para obtener un conocimiento general de la misma y definir áreas o aspectos a verificar.
- Relevamiento detallado de la lógica del programa con el objetivo de obtener información sobre:
- Formato de los archivos
- Significado de los códigos empleados en los archivos
- Fórmulas específicas o criterios de decisión
- Obtención de los archivos necesarios.
- Con el conocimiento de la lógica de la aplicación y los archivos, el auditor podrá preparar los programas para efectuar la simulación paralela.
- Preparación de los datos de entrada y archivos para realizar la simulación.
- Procesamiento y reconciliación. En esta etapa se realiza la corrida de simulación y los resultados se comparan con los producidos por el procesamiento real.
- Evaluación de las excepciones. Se evalúan las excepciones resultantes de las corridas y a partir de ellas se determinan las recomendaciones.
- Procesamiento paralelo
- Pruebas integradas (Minicompañia)
- Explicación previa a nivel de Dirección sobre las características, finalidades y modalidades de la misma. Deben demostrarse los beneficios.
- Aprobación preliminar de la Dirección.
- Determinación de los subsistemas a abarcar, si la prueba se aplicará en forma integral o parcial.
- Identificación de los registros especiales a crear y la forma en que se depurarán las transacciones ingresadas con fines de auditoría.
- Fijación de la forma en que actuará el auditor para simular el comportamiento del sistema, por ejemplo ¿se procesarán las transacciones desde el origen?
- Modelo de los papeles de trabajo en los cuales se volcará el estado inicial de los registros y las modificaciones.
- Aprobación final de la Dirección.
- Información periódica a la Dirección sobre los resultados del sistema de auditoría
- Pistas de transacciones
- Comparación de programas
- Selección de las aplicaciones cuyos programas serán sometidos a revisión, es decir elegir los programas a auditar.
- Corte de programas. A la fecha y hora fijada se procede al “vuelco” de las bibliotecas de programas y de los ejecutables corrientes. Con esta acción el auditor obtiene las versiones de los programas corrientes al momento del corte en lenguaje objeto y puede compararlos con el resultado de la compilación de sus correspondientes simbólicos.
- Examen comparativo de los resultados de la verificación. En caso de discrepancias deberá revisarse cuidadosamente la documentación de análisis y biblioteca de simbólicos para determinar cuál es el código fuente que se corresponde con el objeto corriente.
- Tipo de archivos
- Estructura y descripción de campos
- Relación entre archivos
- Generales
- Propias del sistema
- Selección del producto a utilizar
- Armado del entorno de transferencia
- Transferencia
- Controles de transferencia
- Generales
- Duplicados
- Faltantes
- Importes no numéricos
- Análisis numérico-cronológico
- Propias del sistema
- Códigos inexistentes
- Comparar facturas de proveedores con partes de recepción
Se busca verificar el funcionamiento de una aplicación sin afectar la información residente en sus bases de datos, ni el procesamiento normal de las transacciones que debe atender. Para instrumentar esta técnica, se debe obtener una copia de los programas, extraer una muestra representativa de la información residente en los archivos de datos, luego, realizar el reprocesamiento usando datos de transacciones reales, seleccionadas por el auditor. El reprocesamiento se realiza usando los mismos programas y bases de datos, pero en otro computador. Por su modalidad esta técnica es apta para auditar sistemas de procesamiento batch (diferido), más que aquéllos del tipo on line. También debe tenerse en cuenta que esta técnica no está diseñada para medir tiempos de respuesta, ni la flexibilidad de adaptación a situaciones complejas.
Esta técnica consiste en la creación de un ente ficticio dentro del sistema de procesamiento en operación; por ejemplo crear una división, un departamento, una sucursal, una empresa, un empleado, etc. ficticios, insertados como registro dentro de los archivos reales que utilizan las aplicaciones en producción. A este ente ficticio se le aplicarán registros de transacciones de prueba, confeccionados en forma especial por el auditor. Debe destacarse que se utiliza el mismo sistema que está en producción, dentro de los tiempos de funcionamiento normal del mismo.
Este ente, al estar contemplado dentro de las aplicaciones en producción, permite que su procesamiento no altere los registros reales de la empresa y los resultados de sus informes. En contrapartida, es necesario programar procedimientos especiales para depurar las transacciones ficticias efectuadas por el auditor contra dicha entidad.
La aplicación de esta técnica exige que, además de adaptar los programas, se declare el procedimiento ante los órganos de control institucional correspondientes, como el Banco Central en caso de instituciones financieras, la 59 Auditoría en entornos informáticos DGI, la Bolsa de Valores en caso de cotizar en bolsa, etc. Esta medida procura evitar problemas de índole legal.
Requisitos para instrumentar las pruebas de mini compañía
Esta técnica consiste en establecer rastros (datos especiales), con la finalidad exclusiva de servir como pista de auditoría, en los registros de movimiento que se generan a partir de las transacciones. Los rastros, marcas (tagging) o pistas de auditoría son grabados -como campos ad-hoc- en los registros durante el procesamiento de las operaciones que ingresan al sistema. A estos registros se les incorpora un atributo (campo) especial, por ejemplo, el número de legajo del empleado, la fecha y hora de la operación, el número de terminal, etc. Estos datos sirven para identificar quién y cuándo se realizó la operación. La idea es guardar información que permita realizar un seguimiento de las distintas etapas que siguió el procesamiento de una transacción en particular.
Esta técnica permite rastrear las operaciones reales a partir del examen de los archivos de movimiento que guardan los registros de las operaciones procesadas por el sistema
Esta técnica consiste en el empleo de utilitarios del sistema operativo para comparar dos o más versiones de un mismo programa ejecutable (archivo objeto) de una aplicación. La finalidad es verificar si existen diferencias entre las distintas copias y versiones de los “ejecutables”. Si son diferentes se presume que hubo cambios al programa, por ejemplo, desde la última visita del auditor. En estos casos, el auditor puede pedir que se le informe respecto de dichos cambios y se le proporcione la documentación relacionada (solicitud de modificación, autorizaciones, especificaciones, pruebas, orden de puesta en operación, etc.).
Requisitos para realizar una comparación de programas
Conclusiones:
La prueba de los controles de un sistema de información computarizado, en especial aquellos que requieren de la aplicación de técnicas de re-ejecución de procesamiento, son los temas más esperados por los alumnos que cursan esta asignatura. Es el aspecto que distingue este tipo de trabajos de auditoría respecto de la auditoría tradicional. La esencia del problema es cuáles técnicas aplicar, específicamente, qué combinación de técnicas manuales y computarizadas aplicar para cada tipo de control programado a evaluar. La "alquimia" que requiere estas situaciones dependen del "criterio del auditor"; este último, en base a sus conocimientos, experiencias e intuición selecciona las técnicas que considera más adecuadas para probar el funcionamiento y la calidad de los controles que audita.
PRUEBAS SUSTANTIVAS
Las pruebas sustantivas consisten en comprobaciones diseñadas para obtener evidencia de la validez y propiedad de las transacciones y saldos que van formando los estados financieros de una organización; incluyen comprobaciones de detalles, como las aplicaciones de muestreo o pruebas selectivas, y procedimientos analíticos, diseñados para detectar errores e irregularidades en la información financiera y sus acumulaciones, dichas pruebas son básicas para determinar la opinión final a los estados financieros. Es decir, que se tiene como pruebas sustantivas, los procedimientos de auditoría dirigidos o examinados a obtener evidencia de validez y corrección del manejo contable de las transacciones y los estados financieros y detección de errores o irregularidades en ellos.